Build the coverage line table in UTF-16 code units - #38710

I reviewed this PR and didn't find any bugs. The encoding math checks out and the test is well-constructed, but since this is a runtime logic change with a struct field replacement and explicit drop_elements() handling, a human sign-off would be worthwhile.

What was reviewed:

• Verified the code-unit re-measurement is correct for both Latin-1 and UTF-16 JSC strings (© = 1 unit / 2 UTF-8 bytes; 🐰 = 2 units / 4 bytes; element_length_utf8_into_utf16 via simdutf agrees).
• Checked find_index is a plain binary search over sorted u32 offsets, so feeding it code-unit offsets instead of byte offsets is sound.
• Confirmed no other consumers of the removed line_offset_table field; Box::from(byte_starts) copies before drop_elements(), and the borrow ends before the &mut call.
• The comment at test_command.rs:1598 ("owns a MultiArrayList") is now stale but the code it justifies is unchanged and still correct.

I reviewed this PR and didn't find any bugs. The encoding logic checks out (UTF-16 code-unit count of the UTF-8 re-encoding equals JSC's offset for both 8-bit Latin-1 and 16-bit strings), and the test exercises both BMP and astral characters. Because it's part of a 4-PR stack and the correctness argument hinges on JSC string-representation invariants, a human look would still be worthwhile.

What was reviewed:

• compute() conversion: verified element_length_utf8_into_utf16 yields the right count for Latin-1→UTF-8 (© = 2 bytes → 1 unit) and surrogate pairs (🐰 = 4 bytes → 2 units), matching JSC's index unit in both storage modes.
• drop_elements() ordering: byte_starts is copied into the Box<[u32]> before the mutable borrow; the slab itself is freed by MultiArrayList::Drop at scope exit, so no leak or UAF.
• No other consumers of the removed line_offset_table field; find_index is agnostic to the offset unit.
• The comment-cop bot flags look like false positives — the flagged comments are 2-3 line field/unit documentation, not workaround justifications.

Checked the code-unit invariant for both string shapes JSC can hold here: an 8-bit string with characters above 0x7F (to_utf8 re-encodes each byte to two, element_length_utf8_into_utf16 counts one unit each) and a 16-bit string (astral pairs four bytes / two units, lone surrogates U+FFFD / one unit); both are 1:1 with JSC's offsets. Every other offset use in CodeCoverage.rs now compares against the unit table, including the sourcemap-branch column, which matches what Bun's own maps emit. drop_elements is a real method, frees the per-row column boxes MultiArrayList's Drop leaves behind (a small pre-existing leak), and the later Drop is slab-only. The test fails on 1.3.14 exactly as described (DA:7/DA:10 vs DA:4/5/6, FNH identical). Fine to land from my side.

Nits: the body says the diff is two files but the second commit also touches src/runtime/cli/test_command.rs (a comment); is_all_ascii re-scans text LineOffsetTable::generate already classified (its first-non-ASCII column would do), once per file under --coverage so not worth blocking on; repeatUnits silently needs units % piece.length == 0, both call sites satisfy it, a one-line note would guard the follow-up variants.

LGTM — focused fix that rebuilds the coverage line table in UTF-16 code units so JSC's block offsets map to the right lines when the source contains non-ASCII text.

What was reviewed:

• Verified the code-unit re-measurement is correct for both JSC string kinds: 8-bit Latin-1 (each char = 1 UTF-16 unit) and 16-bit UTF-16 — element_length_utf8_into_utf16 on the UTF-8 re-encoding recovers JSC's offset unit in both cases.
• Confirmed MultiArrayList::Drop is slab-only, so the explicit drop_elements() correctly frees each row's columns_for_non_ascii box with no double-free (it zeroes len); the old code held the full table for the mapping's lifetime and leaked those boxes on drop.
• Checked all four find_index call sites now compare like units (code-unit offsets vs. code-unit line starts); no other consumers of the removed line_offset_table field exist.
• Test design: twin lcov comparison with a ©🐰 banner (30 code units either way; astral char distinguishes code units from both bytes and code points), non-vacuous baseline check on lines 7/10, using dir kept alive by the awaited Promise.all. Fails on main, passes on branch per the gate output.

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

Additional findings (outside the current diff — GitHub can't attach inline comments there):

• 🟣 src/sourcemap_jsc/CodeCoverage.rs — Users running bun test --coverage on a module whose JSC text does not end in a newline get no line coverage for its final line, so an unexecuted last-line function never appears in the lcov record. In the loops at src/sourcemap_jsc/CodeCoverage.rs:762 and :808 every offset on the final line is fed to LineOffsetTable::find_index, which at src/sourcemap/LineOffsetTable.rs:134-149 only returns Some when an i + 1 entry exists or the offset equals the line start, and the equal case is then skipped by the >= guard at :771. Fix: treat offsets at or past the last entry of line_starts as belonging to the last line (fall back to the last index instead of None) in all four lookup loops, and add a fixture whose module lacks a trailing newline.

  Why this was flagged

  Trigger: a coverage-instrumented module whose text as JSC holds it has content on the last line with no trailing newline. Entry point: ByteRangeMapping::generate_report_from_blocks at src/sourcemap_jsc/CodeCoverage.rs:708, called for every covered file. For an offset on the last line, LineOffsetTable::find_index (src/sourcemap/LineOffsetTable.rs:121-150) finds byte_offset < loc_start but i + 1 < len is false, so it advances past the end and returns None; the else { continue; } at CodeCoverage.rs:767 drops the offset. The only offset that returns Some is the exact line start, which the >= guard at CodeCoverage.rs:771 then skips. Result: executable_lines and line_hits never see the last line, so lcov omits its DA: record and the function-level !did_fn_execute fill at :830-837 cannot mark it either. The base used the same find_index on the byte table, but this PR rewrote the table these loops consume without fixing the lookup that still drops the final line.

  Verification: Pre-existing. Trigger: the text JSC holds for a covered file has content on its last line and no trailing newline. src/sourcemap/LineOffsetTable.rs:121-150 find_index: for an offset strictly after the last entry's start, i + 1 < len is false, so it returns None; the only Some is the exact line-start hit, which src/sourcemap_jsc/CodeCoverage.rs:770-773 skips.